Multiplayer interactive video gaming device

ABSTRACT

A multiplayer interactive video gaming device is provided. The device includes a computer workstation assembly, at least one player station, and an interface assembly in operative communication with at least one data port of the computer workstation assembly and configured to receive player input messages from a plurality of the player stations and to output the player input messages to the computer workstation assembly by one or more of the at least one data ports. The interface assembly is operably associated with the at least one player station to route the player input messages from the at least one player station to the computer workstation assembly according to a predetermined protocol so that player input messages generated from simultaneous activation of a plurality of input devices are output to the computer workstation assembly without information loss.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/268,396 filed Nov. 10, 2008, which is a divisional of U.S.application Ser. No. 11/350,255 filed Feb. 9, 2006, now abandoned, whichis a continuation of U.S. application Ser. No. 10/754,598 filed Jan. 12,2004, now abandoned, which is a continuation of U.S. Ser. No. 09/901,135filed Jul. 10, 2001, now abandoned, which is a continuation of U.S.application Ser. No. 08/885,276 filed Jun. 30, 1997, now abandoned.

BACKGROUND OF THE INVENTION

The present invention relates to video gaming systems and, moreparticularly, to improvements in a video gaming machine that permit aplurality of players to simultaneously participate in a game.

Many video gaming machines are configured for single players. Forexample, a video blackjack or poker game machine may have one playerstation from which a player participates in an independent game executedby the machine's game processor. While popular, such games do notprovide the group interaction found in live casino games.

Moreover, single player games are often located in establishmentsfrequented by groups of customers and thus may be unattractive ofcustomers not wishing to separate from their companions.

Video gaming machines typically include a cabinet housing at least aplayer station, a game processor assembly and a video monitor. Theplayer stations include at least one input device by which a playerinputs commands to the game processor. Generally, these input devicesare push-buttons that, when depressed and/or released, trigger switchesthat send a signal to the game processor. However, any suitable inputdevice, for example a joystick or touch screen, may be utilized. Theplayer station also typically includes a currency acceptor by which aplayer deposits coins or paper currency for betting or for paying a feeto play the game. The currency acceptor is often, but is notnecessarily, located proximate the input devices.

The game processor assembly is, generally, a computer assembly includingan integrated circuit computer device that executes a video gamingprogram responsively to the commands input by the player at the playerstation. Often, this processor is a device which is custom programmed toexecute only the video gaming program or related functions. The devicemay be mounted on a custom built circuit board that may include variousperipheral devices as needed or desired. The circuit board isconstructed specifically to operate in conjunction with the video gamingmachine and is typically capable of receiving the input signals directlyfrom each input device.

Multiplayer video games are known which utilize custom circuitry.Development and manufacture of systems including custom circuitry may,however, be expensive, particularly in the early stages. Thus, somegaming programs are developed on conventional personal computers. Thesedevices employ components such as a central processing unit (CPU),memory, and an input/output system. The CPU is an integrated circuit“chip” that can perform a multitude of operations. The input/outputsystem manages data handling among the CPU and other internal orexternal components. Thus, the personal computer is a general purposecomputer, as opposed to single-program “embedded” systems, which mayinclude a dedicated processor device mounted on a printed circuit boardand configured to perform a single function. Personal computers are,typically, relatively small devices, for example as opposed to mainframe computers. A personal computer assembly may be a board including aprocessor and an input/output system. It may also include a cabinetand/or various external and internal components, as should be understoodin this art.

Because it is a multipurpose device, the personal computer assemblytypically has no permanent input or output device having directcommunication to the circuit board or, if there is more than on board,to the main circuit board. Instead, data is conveyed between input andoutput devices and the input/output system by data ports. These portsmay have predetermined uses, for example to receive input from akeyboard or a mouse or to direct output to a printer or monitor.Personal computers also often include expansion slots for additionalcircuit boards which may, in turn, include their own data ports.

Computer software games are known which dedicate certain keys on akeyboard to individual players. However, a keyboard is inadequate for avideo gaming machine, for example because of its physical awkwardness,its tendancy to detract from game realism, and its lack of a mechanismto receive currency for wagers or game fees. Additionally, keyboards aregenerally unable to accept simultaneous inputs from a plurality of keys.

Video gaming machines employing personal computer components without theaddition of custom circuit boards or ports include means for conveyingplayer input data to the CPU through existing components. However,multiplayer games include a relatively greater number of input devices,such as push-buttons, and, consequently, include a correspondinglygreater number of communication lines than required for a single playergame. Because the existing input ports in a typical computerconfiguration are inadequate to directly accommodate these communicationlines, an interface system coordinates data transfer between the playerstations and the data port(s). For example, multiplayer interactivevideo gaming machines are known that, applicants believe, employ anetwork arrangement. Players play individual games from individualplayer stations, each having a keypad, a personal computer circuitboard, and a monitor. In a blackjack game, for example, input from thekeypads is conveyed to the player station circuit board, which mayexecute the individual-player blackjack game responsively to this inputdata and data relating to the dealer's hand provided by a central fileserver computer. The server computer may execute the entire game, withthe player station computers operating the player station input andoutput devices responsively to the server computer.

OBJECTS AND SUMMARY OF THE INVENTION

The present invention recognizes and addresses disadvantages of priorart construction and methods.

Accordingly, it is an object of the present invention to provide animproved multiplayer interactive video gaming device having a pluralityof independent player stations and utilizing personal computer hardware.

More particularly, it is an object to the present invention to providesuch a gaming device incorporating an improved interface assembly.

It is also an object of the present invention to provide an improvedinterface assembly capable of simultaneously processing multiplayerinput messages.

Some of these objects are achieved by a multiplayer interactive videogaming device comprising a computer workstation assembly including aninput/output system and at least one data port, the workstation assemblyincluding a game processor device configured to receive input signals bythe input/output system from one or more of the at least one data portsand to execute a video gaming program responsively to the input signals.The device includes at least one player station including at least onedata input device and configured to output player input messages inresponse to activation of the at least one data input device. The deviceincludes an interface assembly in operative communication with the oneor more at least one data port and configured to receive the playerinput messages from a plurality of the player stations and to output theplayer input messages to the computer workstation assembly by the one ormore at least one data port. The interface assembly and the at least oneplayer station are operably associated with each other to route theplayer input messages from the at least one player station to thecomputer workstation assembly according to a predetermined protocol sothat player input messages generated from simultaneous activation of aplurality of input devices are output to the computer workstationassembly without information loss.

In a preferred embodiment, the system uses a single command entry portto service the player stations in such a fashion that all player stationinput devices are serviced in a prioritized manner that may bearbitrarily defined. All inputs are formatted into messages and queuedso that no information is lost when multiple simultaneous inputs occur.

Preferably, a specialized input device processor is used that serviceseach player station. A variety of input devices, for example joysticks,keypads, buttons, currency acceptors, coin/token acceptors, etc. may beattached. Each player station processor is designed to accept inputs,formulate messages regarding each input, and transmit those messages toa message concentrator. The player stations may communicate with themessage concentrator directly, for example in a “star” arrangement,indirectly, for example in a “daisy-chain” configuration, or through amixture of the two. The message concentrator acts as a buffer forincoming messages from a plurality of player stations which may belocally or remotely connected. The concentrator prioritizes the passingof messages to a workstation using a suitable algorithm, for exampleround robin, first-in first-out, rotating priority, random priority,etc. The queues on the message concentrator buffer all incoming messagesand prevent the loss of input data in situations where multiple messagesarrive simultaneously. The speed of message transfer allows the messageconcentrator processor to support multiple simultaneous input messages.Because most or all input messages may be directed to the workstationthrough a single input port, the concentrator queues input messages, insome prioritized fashion, into an output queue connected to this port.Thus, no messages are lost, and the workstation receives most or allmessages through a single input port, providing increased security andtestability.

The message concentrator extends the workstation input port intomultiple input ports while allowing the workstation to communicate withthe player stations through a single output port. Thus, in a stararrangement, the message concentrator acts as a game network hubmanaging both input and output messages. In a daisy-chain arrangement,the concentrator is the head of the chain which directs messages to theworkstation input port.

The interface assembly is operably associated with the player stationsto route the player input messages to the game computer. In the stararrangement of an exemplary video blackjack game, for example, theplayer stations output the input messages directly to a concentrator.Each player station generates and outputs player input messagesaccording to a predetermined protocol so that input messages resultingfrom simultaneous button activations at that player station are routedto the concentrator without information loss. The concentrator, in turn,receives the player input messages from a plurality of player stationsand routes these messages to the game computer according to its protocolso that player input messages simultaneously received from a pluralityof player stations are routed to the game computer without informationloss. Thus, the concentrator and the player stations are operablyassociated with each other to route the input messages to the gamecomputer so that player input messages generated from simultaneousactivation of a plurality of buttons are output to the game computerwithout information loss.

In an exemplary daisy-chain arrangement of the same game, only oneplayer station communicates directly with the concentrator. Theremaining player stations are linked downstream from the concentrator intandem from the first player station. As in the star arrangement, eachplayer station generates and outputs player input messages according itsprotocol so that input messages resulting from simultaneous buttonactivations at that player station are output from the player stationwithout information loss. The player stations in this arrangement,however, include an additional serial port to receive player inputmessages from downstream player stations. These downstream player inputmessages are received by a player station and passed on to the nextupstream player station or, if the player station is the first in line,the concentrator without interfering with the processing and routing ofits own input messages. Thus, the concentrator and the player stationsare operably associated with each other to route the input messages tothe game computer so that player input messages generated fromsimultaneous activation of a plurality of buttons are output to the gamecomputer without information loss.

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate one embodiment of the inventionand, together with the description, serve to explain the principles ofthe invention.

BRIEF DESCRIPTION OF THE DRAWINGS

A full and enabling disclosure of the present invention, including thebest mode thereof, directed to one of ordinary skill in the art, is setforth in the specification, which makes reference to the appendeddrawings, in which:

FIG. 1 is a perspective view of a preferred embodiment of a multiplayerinteractive video gaming device constructed in accordance with thepresent invention;

FIG. 2 is a block diagram illustration of a preferred embodiment of aplayer station used in a multiplayer interactive video gaming deviceconstructed in accordance with the present invention;

FIG. 3 is a block diagram illustration of a preferred embodiment of aninterface device used in a multiplayer interactive video gaming deviceconstructed in accordance with the present invention;

FIG. 4 is a schematic diagram of a preferred embodiment of playerstation hardware used in a multiplayer interactive video gaming deviceconstructed in accordance with the present invention;

FIG. 5 is a schematic illustration of a preferred embodiment of aninterface device used in a multiplayer interactive video gaming deviceconstructed in accordance with the present invention;

FIG. 6 is a partial schematic diagram of a preferred embodiment of amultiplayer interactive video gaming device constructed in accordancewith the present invention;

FIG. 7 is a block diagram illustration of a preferred embodiment of thepresent invention in a daisy-chain arrangement; and

FIG. 8 is a block diagram illustration of a preferred embodiment of astation architecture used in a multiplayer interactive video gamingdevice constructed in accordance with the present invention in adaisy-chain arrangement.

Repeat use of reference characters in the present specification anddrawings is intended to represent same or analogous features or elementsof the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Reference will now be made in detail to presently preferred embodimentsof the invention, one or more examples of which are illustrated in theaccompanying drawings. Each example is provided by way of explanation ofthe invention, not limitation of the invention. In fact, it willapparent to those skilled in the art that modifications and variationscan be made in the present invention without departing from the scope orspirit thereof. For instance, features illustrated or described as partof one embodiment may be used on another embodiment to yield a stillfurther embodiment. Thus, it is intended that the present inventioncovers such modifications and variations as come within the scope of theappended claims and their equivalents.

The present invention is concerned with an improved multiplayerinteractive video gaming device. Accordingly, FIG. 1 depicts a presentlypreferred embodiment of a multiplayer interactive video gaming device,indicated generally at 10. A cabinet A is divided into player portion 12and a display portion 14. Display portion 14 and player station 12 areattached by a connection piece (not visible in the view shown) throughwhich communication and power lines may be passed. It should beunderstood, however, that various cabinet configurations are possible.For instance, the player portion and the display portion may beunitarily constructed. A multiplayer video gaming device is described inU.S. patent application Ser. No. 08/540,328, the entire disclosure ofwhich is incorporated by reference herein.

Player portion 12 is constructed to simulate a casino blackjack gametable. Three player stations 16 are disposed on the top counter surfaceof player portion 12. Each player station 16 includes a keypad 18 and acurrency acceptor 20. Each keypad 18 includes a plurality of input keys22 through which players participate in the blackjack game. In theembodiment shown, the currency acceptor is a bill acceptor configured toreceive bills of various denominations. The currency acceptor could alsoaccept coins.

In this embodiment, each keypad 18 includes a first row of five, and asecond of two, input keys 22. It should be understood by those ordinaryskill in this art that the use, number, and arrangement of such keys candepend upon the nature of the video gaming program operated within thepresent invention. For example, a blackjack game may require the use ofdifferent keys for different purposes than a poker game. Bill acceptor20 accepts bills for betting and/or game fee purposes.

A ticket dispenser 19 is mounted at each player station. Players may“cash out” at any time by inputting a proper command at their playerstation. Upon cashing out, a printer mounted within the cabinet prints aredeemable ticket indicating the player's winnings via ticket dispenser19.

A functional illustration of a player station 16 is provided in FIG. 2.As indicated above, the player station includes a plurality of inputdevices 24, which may include, for example, player input buttons 22 andcurrency acceptor devices such as bill acceptors 20 (FIG. 1). Playerstation 16 also includes output devices 26, which may include lamps,digital output displays, token dispensers, meters and/or currency returndevices such as ticket dispensers 19 (FIG. 1), which output currency toplayers in the form of redeemable tickets. Currency acceptor and returndevices may include magnetic card readers/writers and IC cardreaders/writers to accept and/or pay out currency electronically.

Player input messages are transferred from the player stations to aworkstation including a game processor running the video gaming program.The workstation may include a data port, such as a serial port or akeyboard port, an input/output system, and a suitable communicationarrangement communicating with a remote game computer. Accordingly, aworkstation assembly may comprise a local computer, to receive inputfrom a plurality of player stations, and a remote computer, to receiveinput signals from the local computer and execute the game programresponsively to such signals. The local and remote computers maycommunicate through any suitable arrangement, for example telephonesystems or local area network systems. The remote computer's gameprocessor thereby receives input signals from the data port of the localcomputer. In this arrangement, a single game processor may operate aplurality of remote player station groups. Alternatively, a workstationassembly may comprise a remote computer and a communications system,such as a telephone system or local area network system, through whichmultiple player stations communicate with the remote computer. Thus, aplurality of single-player stations separated by relatively longdistances may participate in a single-player or multi-player gameoperated by the remote computer. Additionally, however, the workstationmay be a personal computer assembly including an input/output system,one or more data ports and a game processor device in a local unit.Although a personal computer assembly is the workstation type most oftendiscussed herein, it should be understood that this is for exemplarypurposes and that all workstation configurations, provided they aresuitable for a given embodiment, are within the scope and spirit of thepresent invention. The remote computer in any of these arrangements mayoperate a progressive jackpot feature in which all communicating playerstations may participate.

The player input message is the information input at the player station,for example by player activation of a button or bill acceptor or bysystem activation of a maintenance condition at a token dispenser, andconveyed to the personal computer through the player station andinterface assembly equipment. During the transmission, the message maytake a variety of forms. For example, in a preferred embodiment asillustrated in the figures, one type of player input message may beinput by pressing a button 22 (FIG. 1). As discussed in more detailbelow, this delivers a signal, for example a pulse, to the playerstation control mechanism, which identifies the pulse and selects anappropriate ASCII input code. The player station outputs the ASCII inputcode to the interface assembly, where the interface assembly controlmechanism converts the input code to a scan code for transmission to thepersonal computer.

Another type of player input message may be input by activating a billacceptor. The bill acceptors may deliver input signals to the playerstation control mechanism in a variety of forms, for example as a seriesof pulses or as a digital word. It should be understood that all suchconfigurations are included within the scope and spirit of the presentinvention.

The internal components of player station 16 are illustratedfunctionally in FIG. 2 by player station processing system 28,transmitting buffer 30 and receiving buffer 32. In a preferredembodiment, processing system 28 receives data directly from inputdevices 24. If many input devices are employed on a player station,however, it is possible to create a row/column matrix for routing datavia multiplexing to the processing system, as should be understood inthis art.

In operation, if the processing system 28 detects, for example, afalling pulse indicating that a particular button has been pressed, theprocessing system associates the pressing of that button with anappropriate code. In a present embodiment, the code is a four charactermessage. The first character indicates that the message is beginning.The second character indicates the message type, which identifies themessage as, for example, a button message or a dollar bill acceptormessage. The third character provides the message information, forexample that button number three has been pressed. The fourth characterindicates the end of a message. The coding prevents information lossand/or message scrambling when the messages are queued or dequeued. Amore detailed description of the message structure is provided in theAppendix. It should be understood, however, that this message structureis provided for exemplary purposes only. For example, there may bechanges to certain delimiting characteristics and addresscharacteristics to avoid conflicts with other devices which may be usedin the system. For example, in one embodiment, the lead, or start,character has been changed from “control-A” to “control-V.”

After creation of the appropriate code, the message is stored intransmitting buffer 30. A serial port 34 is provided on player station16 to output the data stored in buffer 30. The serial port converts datafrom a parallel format to a serial format to transmit and converts froma serial format to a parallel format to receive. Status signals indicatewhether the transmitter is available (empty) and whether the receivercontains data (full). Two data lines, transmit line 36 and receive line38, are connected to serial port 34. Processing system 28 monitors astatus signal associated with transmit line 36. When a “transmitterempty” condition is indicated, the next message character in transmitbuffer 30 is transmitted through serial port 34 along transmit line 36.

Data received from receive line 38 through serial port 34 is stored inreceive buffer 32. Processing system 28 receives messages from buffer 32and acts according to instructions provided thereby. Thus, processingsystem 28 may be caused to illuminate lamps at the player station,dispense coins through a token dispenser, print a cash out ticket, orother desired functions.

In a star arrangement, each player station 16 communicates with acentral interface device for transferring player input messages to thegame computer. As illustrated in FIG. 3, each player stationcommunicates by its respective transmit line 36 and receive line 38 withthe interface device 40 via serial ports 42. Five player stations may beemployed within the construction illustrated in FIG. 3, although lessthan five, for example three, may be used. In a daisy-chain arrangementas illustrated in FIG. 7, the player stations may be connected in tandemso that messages move in and out of successive player stations untilreaching the central interface device. Each player station includes anadditional serial port and buffer, and each player station processingsystem generates new messages to the next player station to pass on amessage received from a prior player station.

Referring again to FIG. 3, interface 40 includes receive buffers 44 andtransmit buffers 46 corresponding to each player station. An interfaceprocessing system 48 controls the transfer of information between thereceive buffers 44 and the interface output buffer 50 and between theinterface input buffer 52 and the transmit buffers 46. When processingsystem 48 receives an incoming message from a receive buffer 44, theprocessing system converts the message to a scan code which theoperating system on the game computer will recognize. The scan codes arerouted to and stored in transmit buffer 50, which communicates with thegame computer via interface keyboard port 54. A transmit line 56connects interface keyboard port 54 with a game computer keyboard port.Processing system 48 monitors transmit line 56 and, when no data ispresent on transmit line 56, outputs the scan codes stored in transmitbuffer 50 to the game computer over transmit line 56 through keyboardport 54.

The scan codes are received by the game computer through its keyboardport. The use of the game computer keyboard port has certain advantages.For example, general purpose computers are typically sold with operatingsystems configured to receive and recognize scan codes from the keyboardport. Thus, the game program may be constructed around the standardkeyboard key strokes that the scan codes represent, and the video gamingprogrammer may rely on the built-in operating system to receive andprocess input data without having to program a custom data operating anderror checking system. Some recent operating systems, for exampleWINDOWS95, receive and process data from operating system ports otherthan the keyboard port, for example certain COMM ports. While theoperating system does not recognize “key up” and “key down” events fromthese other ports, applications running on the operating system mayotherwise take advantage of the operating system to deliver data fromthem. For illustrative purposes, not for purposes of limitation,communication by keyboard port is primarily discussed herein.

Data is routed between the player stations and the game computer throughprocessing systems 28 and 48, illustrated in FIGS. 2 and 3, and theinput and output buffer systems, without loss of information. Thus, iftwo players press input buttons at their respective player stationssimultaneously, both input messages will be received by the gamecomputer.

Commands from the game computer to player station output devices aretransmitted to interface input buffer 52 via interface device serialport 58. Processing system 48 receives messages from buffer 52,determines to which player station the command should be forwarded, andstores the command in the appropriate output buffer 46 for transmissionto the player station via the corresponding serial port 42. If thesystem is daisy-chained, only one transmit buffer is required. As eachmessage is received by a player station, it is relayed to and examinedby the next player station. If the message is found to be for thisplayer station, that station's processing system performs the requestedaction.

Processing system 48 may also communicate directly with input devices 24and output devices 26. These may include the same input and outputdevices discussed above with respect to the player stations. That is,the input and output devices of a single player station may be directlyconnected to interface device 40 without a player station processingsystem 28 and buffers 30 and 32 (FIG. 2) that are associated with theindividual multiple player stations. Thus, the game computer/interfaceassembly may be used with player stations of single player games whichdo not have such processing systems or buffers. Accordingly, the gamecomputer/interface assembly may be used interchangeably with amultiplayer or a single player configuration. Video gaming machines maybe constructed with removable player station units so that the game maybe converted between a multiplayer game and a single player game simplyby interchanging the player station unit or units. Provision may be madeto reprogram or convert the game computer to a new or previously storedprogram to enable operation of the new game.

In another preferred embodiment, the interface device may be physicallyembodied on a player station so that this player station communicateswith the game computer through the keyboard port. Other player stationsoutput messages to the game computer through this first player stationto avoid loss of information. Player station units may be linked to thefirst player station in a star or daisy-chain arrangement and may beadded or removed to achieve a desired number of player stations.

As described above, processing system 48 receives incoming codes fromthe player stations and converts the codes to scan codes which theoperating system on the game computer will recognize. Since there are afinite number of messages which will come from any player station, aunique scan code may be assigned to each particular message from eachplayer station. This may be accomplished, for example, by convertingplayer station messages into keyboard scan codes. Thus, in a preferredembodiment, each player station includes similar input devices in asimilar arrangement and outputs the same messages for the samecorresponding devices. Processing system 48 assigns scan codes basedupon the player station message and the player station itself. Thus, theassignment of the scan code depends upon the particular message and theparticular player station from which the message is received.

It should be understood, however, that various suitable configurationsare possible. For example, while in a preferred embodiment the playerstation processing systems assign ASCII codes as the player stationmessages, various coding processes may be employed. Thus, for example,scan codes could be assigned at the individual player stations,eliminating the need to make the assignment at the interface device.

In the illustrated local unit embodiment, the game computer is,preferably, an IBM PC/AT compatible personal computer. Thus, the scancodes assigned by processing system 48 are compatible with the operatingsystem provided on those computers. The operating system is configuredto receive the scan codes from the computer keyboard port and to usethose codes for operating system functions and/or higher levelfunctions. In particular, the IBM PC AT compatible computers may receivethe scan codes and convert them to ASCII codes, which may be output to ascreen and which may be used in commercial or custom software, includingthe gaming program.

A schematic illustration of a player station is provided in FIG. 4. Aplurality of buttons are indicated by button groups 60, 62 and 64. Eachbutton group may include up to eight individual input buttons 22 (FIG.1), for a total of 24 input buttons. A bill acceptor 20 is controlled bya series of dip switches 66, which may be used to program the billacceptor to, for example, accept certain bill denominations and/orselect serial or pulse mode operation.

Output devices includes lamp groups 68 and 70 and digital output groups72, 74 and 76. As with the button groups, each lamp group and eachdigital output group includes eight lamps and eight digital outputdevices, respectively. It should be understood, however, that all of theavailable input and output devices may not necessarily be employed in aparticular game; the illustrated construction merely indicates that theyare available. Other output devices include token dispenser 78 andticket dispenser 19.

Data is transmitted to or from these input and output devices on 8-bitdata bus 80 and is controlled by field programmable gate array 82. Gatearray 82 may be, for example, a Xilinx XC3042 or XC5202 gate array orother suitable device.

Data transfer from the player station is controlled by a processor 84which, in one preferred embodiment, is an 8051-compatible microcomputerhaving one or two on-chip serial ports. It should be understood thatother processing devices may be used, for example those includingon-board EPROMs. Although processor 84 includes a certain amount ofmemory, SRAM 86 provides additional storage. Together, this memoryserves as the player station buffers. EPROM 86 provides storage for theprogramming for processor 84 and the look-up tables by which input codesmay be assigned to particular input signals. A PAL (not shown), forexample a 20V8 PAL, is provided to decode the microprocessor addressrange into three ranges—EPROM, processor and input/output devices,including the gate array.

In operation, processor 84 controls gate array 82 to input and outputdata to and from the input devices and output devices. An internal logicsignal of the gate array 82 causes gate array 82 to send an interruptsignal to processor 84 every 25 milliseconds. In response to thisinterrupt command, processor 84 orders gate array 82 to sequentiallyplace the contents of the data registers of the respective button groupson data bus 80. Thus, if a player presses one of the buttons in buttongroup 62, the corresponding position in the button group 62 registerchanges state. Following the next 25 millisecond interrupt signal fromgate array 82, processor 84 causes gate array 82 to connect the registerof button group 62, in order among the other button groups, to commonbus 80. In the embodiment depicted in FIG. 4, button group 62 mayinclude up to eight buttons so that each button position of the buttongroup 62 register may correspond to a data line on eight bit bus 80.Thus, of the eight data lines input to processor 84 from bus 80, sevenare at a normal state while one has changed state due to the pressedbutton. Because processor 84 causes gate array 82 to connect the buttongroup registers to the common bus in a certain order, processor 84 knowswhich button group is connected to the common bus at any time. In thismanner, the processor identifies the particular button group from whichit receives an input message. The particular button or buttons withinthe button group is determined by the line or lines on common bus 80that have changed state.

As indicated in FIG. 4, button group 60 communicates with processor 84indirectly, through gate array 82. The buttons of button group 60communicate directly with the gate array, which acts as the register forbutton group 60.

Once processor 84 determines that a particular button in a particularbutton group has been pressed, it generates an ASCII code correspondingto that particular button. This can be done, for example, either by analgorithm that is part of the processor 84 program or according to alookup table stored in EPROM 88. Once the code is established, it istranslated into a message which is stored in a transmit buffer in SRAM86 until processor 84 determines that the serial transmitter (not shown)of serial port 34 is free. When the output line is free of data,processor 84 outputs the stored ASCII codes from SRAM 86 through serialport 34 to the output data line.

If two or more buttons in a button group are simultaneously pressed,processor 84 converts each signal into a corresponding ASCII code andstores signals in SRAM 86 according to a predetermined-order, forexample depending upon the data line over which they were received. Thecorresponding messages are output through serial port 34 in the order inwhich they are stored in SRAM 86. By this protocol, simultaneous buttonactivations are accommodated without information loss.

This assumes, however, that the activation of all the buttons representsinformation—data that the game program should receive to operateproperly. In some games certain buttons, for example “Bet” or “Hit”buttons, are inappropriate at certain times. While the game programitself may be configured to ignore the data resulting from these buttonactivations once such data is received, the program may controlprocessors 84 and 96 to mask these buttons so that the data is notforwarded to the game computer. Additionally, the processors may beprogrammed to recognize one or more button activations, and notrecognize one or more others, when buttons are simultaneously activatedwhere the latter buttons may always be ignored in favor of the formerbuttons. In any event, the video gaming device may be configured toignore button activations which do not represent information whilemaintaining the ability to process those simultaneous button activationsthat do.

Processor 84 may also receive inputs from bill acceptor 20, tokendispenser 78 and/or ticket dispenser 19. The inputs from bill acceptor20 primarily relate to the amount of currency input by the player.Inputs from the token dispenser generally concern errors, for examplethat there are insufficient tokens in the dispenser. Inputs from ticketdispenser 19 may include error signals but may also include signalsindicating, for example, that a ticket has been printed and dispensed.

These devices are programmed to output an appropriate message to gatearray 82 in a predetermined format, for example ASCII hexadecimal. Uponreceipt of such a message, gate array 82 stores a digital signalindicating the origin of the message and sends a second interrupt signalto processor 84. Upon receipt of this type of interrupt signal,processor 84 reads the identifying signal stored in gate array 82 andcauses gate array 82 to pass the input from that particular device tocommon bus 80 where it is read by processor 84. Processor 84 convertsthese messages, either by a program algorithm or by a lookup table, toan ASCII code which is output by serial port 34.

Data commands to a player station are received through serial port 34 byprocessor 84, which stores the command in SRAM 86. The command willidentify a particular output device, for example ticket dispenser 19 ora lamp in lamp group 70. Assuming the latter, processor 84 causes gatearray 82 to connect processor 84 to lamp group 70, at which timeprocessor 84 writes appropriate data on bus 80 to drive the particularlamp in lamp group 70 while preserving the previous state of the otherlamps in the group. Instructions to bill acceptor 20, token dispenser 78and ticket dispenser 19 are generally in the form of digital words whichare downloaded to the particular devices through gate array 82. Theseoutput devices are configured to receive this information and actaccordingly. The particular construction and configuration of thesedevices are well known in the art and need not be described herein.

Player stations 16 communicate with the game computer through aconcentrator board 40 (FIG. 3). A schematic illustration of concentratorboard 40 is provided in FIG. 5. In the star arrangement, each playerstation communicates with concentrator board 40 from the playerstation's serial port 34 (FIG. 4) to a serial port on the concentratorboard. Four serial port groups 90 are provided on the concentratorboard. Each serial port group 90 includes four serial ports, each havingan input line and output line. Thus, each serial port group has eightdata lines in communication with an eight bit data bus 92. Accordingly,in the configuration illustrated in FIG. 5, sixteen player stations maybe connected to concentrator board 40, although in preferred embodimentsthree or five player stations are employed.

Field programmable gate array 94 controls communication of data alongbus 92 between a processor 96 and the ports and devices communicatingwith the bus. Any suitable processing device, for example an8051-compatible microcomputer, may be used. Gate array 94, EPROM 98 andSRAM 100 may include the same or similar components as the correspondingcomponents on the player stations.

EPROM 98 stores the program executed by processor 96. Processor 96 mayinclude its own internal memory for use as buffers. Preferably, however,SRAM 100 is included to provide additional memory.

A player input message from a particular player station is received at aserial port, which communicates with that player station, in one of theserial port groups 90, where it is stored in the serial port groupregister. Upon receipt of an interrupt signal periodically sent by gatearray 94, processor 96 instructs gate array 94 to sequentially connectthe register of each serial port group 90 to the eight data lines ofcommon bus 92. In this manner, processor 96 is able to determine fromwhich serial port, and therefore from which player station, it receivesdata. Processor 96 stores the incoming data either in its internalmemory or in SRAM 100.

As discussed above, the incoming messages are in the form of ASCIIcodes. Processor 96, either by computer program algorithm or by a lookup table stored in EPROM 98, assigns a scan code appropriate for theparticular ASCII character from the particular player station. The scancode is then stored in SRAM 100.

Processor 96 monitors the status of keyboard output port 102 by gatearray 94. If the output data line is clear, processor 96 outputs thestored scan code from SRAM 100 over bus 92 to gate array 94 to keyboardoutput port 102. Keyboard output port 102 communicates with the gameprocessor via a personal computer keyboard port.

Data may be downloaded from the game computer via a keyboard input port104 or serial port 106. If data is downloaded to keyboard input port104, gate array 94 sends a second interrupt signal to processor 96,which then instructs gate array 94 to put the data on common bus 92 forstorage in SRAM 100. Data downloaded through serial port 106 is storedby processor 96 in SRAM 100. If the incoming message is a command for aplayer station, processor 96 causes gate array 94 to connect theappropriate serial port in the appropriate serial port group 90 tocommon bus 92 and outputs the command to the common bus.

Concentrator board 40 also includes connections for button groups 108and 110, lamp group 112, digital output device group 114, switches 116,bill acceptor 118, token dispenser 120, and ticket dispenser 122. Theseconnections are provided for direct connection of their associateddevices to concentrator board 40. Thus, concentrator board 40 may beconfigured to function as a single player station, operating asdescribed above regarding player stations 16 (FIG. 4). Thus, in apreferred embodiment, a game cabinet may be constructed housing apersonal computer assembly and a concentrator board assembly wherein theplayer stations are removable. Thus, multiple player stations may beinstalled and connected to serial ports in serial port groups 90 forcommunication to the game computer through the concentrator board. Thegame may, however, be converted to a single player game by removal ordeactivation of the multiple player stations and installation of asingle player station whose components connect directly to theconcentrator board 40 as indicated in FIG. 5. Multiple alternative gameand operating programs may be stored in, or programmed into, the gameprocessor and the concentrator board processor so that they may operatein the new configuration. Thus, a game assembly may be convertiblebetween a single player and a multiplayer configuration.

FIGS. 7 and 8 illustrate a daisy-chain arrangement of the presentinvention. In the embodiment illustrated in these figures, a serial portof game computer 124 is the head of a bidirectional RS-232 networkimplemented using intelligent controller cards, each having two serialcommunications ports termed the “up” and “down” ports. In general,commands from the game computer flow first into the concentrator upport, the first external node in the network. Commands from the gamecomputer are echoed to the concentrator down port and output to thefirst player station, player station 16 a, up port. If the command isintended for processing by this player station, the command message isparsed and queued. Otherwise, the message is echoed to the playerstation's down port and output to the next player station up port.Player input messages generated by the player station and player inputmessages received from other player stations through the playerstation's down port are queued and dequeued, for example in round-robinfashion, to the station's up port as complete messages as they becomeready.

Command messages and player input messages are processed at thenon-interrupt level. Serial port buffers are managed at the interruptlevel. This prevents loss of data when the processor is busy with localtasks.

In this fashion, command messages are passed from the game computer tospecific player stations, and input messages from the player stationsare passed up to the game computer. The concentrator 40 receives commandmessages from the serial communications port of game computer 124. Itroutes input messages from player stations to the game computer throughits keyboard port. Thus, input messages may be directed to the computeras keyboard scan codes as described above.

The tandemly-linked player stations illustrated in FIG. 7 may beconfigured as shown in FIG. 4 with the use of a second serial port 34 toprocessor 84. Thus, one of the serial ports 34 is used as the up port,and the other is used as the down port. The up ports and down ports arebidirectional. Thus, assuming player station 16 illustrated in FIG. 4 isplayer station 16 b illustrated in FIG. 7, the up serial port 34receives command messages from, and outputs input messages to, the downport of player station 16 a, while the down port 34 receives inputmessages from, and outputs command messages to, the up port of playerstation 16 c. Command messages received by up port 34 are stored in SRAM86. The command message includes an identifier indicating for whichplayer station it is intended. Processor 84 reads the identifier and, ifthe command message is intended from player station 16 b, acts upon themessage as described above. If, however, the command message is intendedfor player station 16 c, processor 84 directs the message to down port34 for output to player station 16 c.

Player station 16 b receives input messages from player station 16 cthrough down port 34 and stores these messages in SRAM 86. Since thesemessages are intended for the game computer, processor 84 directs thesemessages to player station 16 a through up port 34. The input messagesfrom player station 16 b are also passed to player station 16 a throughthe up port.

Processor 84 may simultaneously receive and store messages from its dualserial ports 34 (the up and down ports). If a message is to be passedthrough the player station, processor 84 may simply direct the messagefrom one serial port to the other, or it may place the message on SRAM86 for output at a later time. In any event, a player station mayprocess command and input messages received from external sources whilegenerating its own input messages without losing information even if,for example, a command message and an input message are received at thesame time a button is pressed at the player station. Thus, from theperspective of player station 16 b, the interface between it and gamecomputer 124 is concentrator 40 and player station 16 a.

A receive-only serial device, such as sign 142, may be connected on theend of the chain. The network messaging protocols may be designed toallow other devices to be connected without mutual interference. Thatis, the message formatting for the player station network may bedifferent than that used by the sign, and the two protocols may coexistwithout interference.

FIG. 8 illustrates one preferred player station network architecture.There are three distinct processing levels for handling network traffic.At the hardware level, two standard on-chip serial communications portshandle all data serialization and deserialization. At the interruptlevel, the on-board processor handles characters received from or sentto the serial ports. At the interrupt level, the processor manages tworeceive buffers and two transmit buffers. At the applications level,where all of the application's code has the same execution priority, theprocessor queues and dequeues messages in three queues. An input queueholds parsed command messages for processing by the applicationfirmware. Two output queues hold complete input messages from the playerstation to be passed, using an arbitrary prioritization scheme, to theup port's output buffer. Round-robin prioritization, for example, may beused to empty the output queues.

The above description illustrates both a star and daisy-chainarrangement. The concentrator and player stations support eithertopology. While the concentrator arrangement may exhibit superiorperformance, the daisy-chain arrangement is, generally, less expensive.The choice among star, daisy-chain and a combination of the twoarrangements will depend upon the requirements of a specificapplication.

Referring now to FIG. 6, personal computer assembly 124 houses a gameprocessor such as a CPU 126, for example a PENTIUM processor, forexecuting a blackjack gaming program responsively to the player inputmessages from player stations 16 (FIG. 4). An input/output system suchas a BIOS 128 receives the input messages from concentrator boardkeyboard output port 102 (FIG. 5) by keyboard port 130 and bus 132. BIOS128 outputs a signal to CPU 126 over a bus 134. As should be understoodby those of ordinary skill in the art, BIOS 128 may decode or encodesignals received by CPU 126 depending upon, for example, theconfiguration of the personal computer assembly.

Moreover, a variety of circuitry configurations are possible within therange of personal computers. For example, a variety of input/output,memory (for example RAM 136), buses, and other devices may be arrangedin various suitable configurations. Furthermore, various methods may beemployed utilizing such devices and configurations in communicatinginformation between keyboard port 130, or other suitable data inputport, and CPU 126. It should be understood that all suitable suchpersonal computer configurations may be employed in accordance with thepresent invention.

As it executes a video card gaming program, CPU 126 outputs videodisplay signals to a monitor 138 via a parallel port 140. The video cardgaming program executed by CPU 126 permits interactive participation bya plurality of players at player stations 16 (FIG. 1).

The video card gaming program is preferably written in an “event-driven”language such a Visual Basic or Visual C. An event-driven programperforms operations responsively to “events,” such as the depression ofa push button that, in turn, causes BIOS 128 to output a signal to CPU126. As should be understood by those of ordinary skill in this art,personal computers are generally equipped with operating systems whichare configured to manage communication between the personal computer andthe software programs. In particular, the operating system is configuredto recognize certain signals, for example scan codes received by thekeyboard port and to convert such signals into predetermined codes, forexample ASCII codes, which may be utilized by the program. In apreferred embodiment, personal computer assembly 124 is anIBM-compatible system using a MSDOS-compatible operating system. Thescan codes assigned by the concentrator board (FIG. 5) are converted bythe operating system to ASCII codes which are utilized in operation ofthe video card gaming program.

Although a variety of card gaming programs may be utilized in accordancewith the present invention, in one presently preferred embodiment CPU126 is configured to execute a blackjack game wherein the gaming programgenerates a “dealer's” blackjack hand on monitor 138 that is visible tothe players at the player stations. The players submit wagers, accept orreject card “hits,” and select game options via the keys at the playerstations. The player's hands are displayed on monitor 138 along with thedealer's hand in a manner similar to the display of cards on a casinoblackjack table. Various versions of the basic blackjack or “21” gameare known and may be employed in accordance with the present invention.

Various types of metering devices may be employed within the system. Forexample, an “in” meter may be used to count the amount of money put intothe gaming machine. The construction of such meters, which should bewell understood in the industry, need not be described herein.Typically, however, the meter is a relatively simple counter which isincremented by pulses. The in meter may be implemented within the systemas are various input/output devices illustrated in FIG. 4. Thus, one ormore such meters may communicate with common bus 80 directly, likebutton group 64, or through gate array 82, like button group 60.

In operation, the game computer may receive data from a player station'sbill acceptor 20 corresponding to an amount of currency accepted. Thegame program recognizes this amount and causes the game computer orprocessor 84 to output an appropriate number of pulses to the in meterso that the in meter properly increments, thereby recording the amountof money input at the player station. The number of pulses sent to themeter depends upon the denomination by which the meter is to count. Forexample, if the machine accepts currency in dollar, or greater,increments, the meter may increment for each dollar input at the machineor player station. Thus, if a player inputs a five dollar bill, themeter is incremented five times.

By controlling the meter through the game program, various types of billacceptors may be used, for example those which output data by pulses orby digitally formatted signals. Various types of currency may beaccepted, for example paper, coins or electronic media.

Other such meters may be attached within the system in a similar fashionfor other purposes. For example, the game program may increment an “out”meter to record the amount of money cashed out at the machine or playerstation, for example through a coin or bill hopper, ticket dispenser orelectronic output mechanism. The program may also increment a “creditsplayed” meter, to record how much money is wagered at a player station,and a “credits won” meter, to record the amount of money returned to theplayer station as winnings. Additionally, switches may be provided atthe game cabinet's main door through which the game hardware isaccessed, and/or, for example, at one or more cash drawers, that changestate upon opening or closing of the door or drawers. These switches maycommunicate with the game computer, as do other peripheral devices suchas the buttons and lamps described above, so that the game computer isnotified of the openings and/or closings. Upon notice of a door ordrawer opening, the game computer may increment a meter installed forthis purpose. Such an arrangement may serve a security purpose, sincethe game's owner or operator may monitor the meter to assure that thegame has not been opened since the previous meter reading. It shouldtherefore be apparent that various game “events” may be metered usingthe arrangement and construction of the present invention.

The meters may be employed in a variety of game configurations. Forexample, as described above, they may be used in conjunction with aninterface assembly as described herein that facilitates communicationbetween player stations and a workstation running the game. They mayalso be used, however, in arrangements without such an interfaceassembly, such as embedded systems or networked player stations notemploying a common interface. In an embedded system, the meters cancommunicate with a dedicated processor on a printed circuit boarddirectly, for example through direct wiring to the circuit board, orindirectly, for is example through processors at the player stations.The dedicated processor can increment the meters appropriately asevents, such as money in, money out, money wagered, money won and dooropenings or closings, occur. In the networked arrangement, the metersmay be incremented by a server, either directly or through the playerstations, or by player station processors.

As noted above, one or more meters may be employed to record data foreach player station. Alternatively, in a multiplayer game, a group ofmeters may be used to record such data for the multiplayer game as awhole, rather than per player station. Such meters may be attached asperipheral devices to the concentrator board 40 (FIG. 5) or to one ofthe player stations. Furthermore, meter groups, whether for use with thegaming machine as a whole or with individual player stations, may beplaced on their own boards. Such a board may include, for example, amemory device, a microprocessor and, possibly, an FPGA. Its constructionand operation would be similar to that of the player station 16arrangement illustrated in FIG. 4, but on a smaller scale. In a stararrangement, such a board could communicate with an interface processingsystem 48 by a serial port 42 (FIG. 3). In a daisy-chain arrangement,the meter board, or boards, may be linked with the player stations.

Moreover, the player stations themselves may be constructed by multiplesuch boards, each containing a certain group of input and/or outputdevices. Thus, a player station may have a board for its meters and aseparate board for its buttons. In this manner, defective components maybe replaced without requiring replacement of the entire player stationhardware. Further, a cabinet may be more easily reconfigured to play adifferent game which might require a different configuration of certainplayer station devices.

While preferred embodiments of the invention have been described above,it should be understood that any and all equivalent realizations of thepresent invention are included within the scope and spirit thereof. Theembodiments depicted are presented by way of example only and are notintended as limitations upon the present invention. Thus, whileparticular embodiments of the invention have been described and shown,it will be understood by those of ordinary skill in this art that thepresent invention is not limited thereto since many modifications can bemade. Therefore, it is contemplated that any and all such embodimentsare included in the present invention as may fall within the literal orequivalent scope of the appended claims.

APPENDIX I. General Message Structure

The serial port messages to the various devices on the player stationsare routed to the spare communications port of the game computer, anIBM-compatible personal computer. This appendix defines the generalstructures of the messages needed to control the various devices.

There are two types of serial port messages: output messages and inputmessages. The output messages are those sent from the game computer tothe various devices. Input messages are those received by the gamecomputer from the various devices. Not all devices necessarily respondto commands from the game computer.

1.1 Output Message Structure

The basic output message structure comprises a one character header, aone character address, a data field of unspecified length, and a singlecharacter terminator. The header and the terminator are the ASCII NULLcharacter, 0x00. The address character identifies the player station towhich the output message will be routed.

The data field comprises an unrestricted number of characters. Thecharacters in the data field may include any ASCII codes other than theASCII NULL code. Specific messages to a device will have a definedstructure discussed below.

The general output message structure can be summarized as:NULL—address—data field—NULL.

Table one summarizes exemplary defined addresses. Either upper case orlower case characters may be used as the address character. The ‘*’address character is used to broadcast the data field of an outputmessage to all the player station control boards.

All messages are sent using the above-defined format. This applies toall defined messages even if it is possible to distinguish betweenmessages having fixed length data fields. Because the ASCII NULLcharacter is used for both the header and terminator of a message, it ispossible to use the terminator of one message as the header for the nextmessage. Thus, two consecutive ASCII NULLs are not required to separatemessages.

TABLE 1 MESSAGE ADDRESSES Destination Address Player Station #1 ‘A’Player Station #2 ‘B’ Player Station #3 ‘C’ Player Station #4 ‘D’ PlayerStation #5 ‘E’ All Player Stations ‘*’ Concentrator Board ‘F’ Printer‘P’ Progressive Sign ‘S’

1.2. Input Message Format

The basic input message structure comprises a one character header, aone character message type identifier, a one character address, a datafield of unspecified length, and a single character terminator. Theheader and the terminator are the ASCII NULL character. The addresscharacter identifies to which board the messages will be sent. Themessage type identifier character is defined in Table 2. The data fieldcomprises an unrestricted number of characters. The characters in thedata field may comprise any ASCII codes other than the ASCII NULL code.Specific messages from a device will have a defined structure discussedbelow.

The general input message structure can be summarized as:

NULL—type—address—data field—NULL. Input messages use the same addressidentifier character as defined in Table 1.

TABLE 2 INPUT MESSAGE TYPE IDENTIFIERS Message Type Identifier Error ‘?’Status ‘!’ Credit Entry ‘$’ Button Action ‘@’

II. Output Messages: PLAYER/CONCENTRATOR

This section defines the output messages from the game computer that areprocessed by the player station control board (PLAYER) or the playerstation concentrator board (CONCENTRATOR). These two boards support manyof the same functions and devices in common. However, the CONCENTRATORalso routes serial printer data streams to a serial printer which is notsupported by the PLAYERs. Therefore, all the common messages are definedin subsection, and CONCENTRATOR-specific commands are defined insubsection.

2.1 Common Output Messages to PLAYER/CONCENTRATOR

The PLAYER and CONCENTRATOR boards support a common set of devices.Therefore, there is a common set of output messages between them. Thereare five common output messages:

2.1.1. Lamp/Relay Control Message

The lamp/relay control message controls the state of each lamp/relaydriver pin. The PLAYER board has fourteen drivers. The CONCENTRATORboard has seven drivers. The driver pins are addressed sequentially from1 to 14; the CONCENTRATOR drivers are addressed from 1 to 7. Thelamp/relay control message takes two forms. The first allows each driverto be individually addressed and to be turned on or off. The secondsimultaneously addresses all the drivers and turns each on or off basedon a four digit ASCII Hexadecimal code. Each bit represented in theASCII Hex code turns on the lamp/rely if the bit is set to a logical 1or turns off the lamp/relay if the bit is reset to a logical 0.

The data field format of the first lamp/relay control message formed is:

-   -   ‘L’{h} {‘0’|‘1’}.        The ASCII Hexadecimal number {h} is the number of the lamp/relay        driver to be controlled. The valid range of {h} is 1 (‘1’) to 14        (‘E’).

The data field format for the second lamp/relay control message form is:

-   -   “L0”{hhhh}.        The string {hhhh} represents a four digit ASCII Hexadecimal        number string. The typical range of this string will be        0(“0000”) to 4095(“0FFF”). The least significant bit, bit 0,        controls lamp/relay 1, and bit 13 controls lamp/relay 14. The        remaining bits should be programmed as zero.

Lamp/relays 13 and 14 are typically reserved to control two meters. Forthis reason, the typical range for this form of the lamp/relay controlmessage value string contains a ‘0’ for the most significant four bits.

The user may use lamp/relay drivers 13 and 14 to drive lamps, relays, ortotalizing meters. The firmware does not eliminate drivers 13 and 14from the range of lamps/relays drivers that can be controlled by thismessage simply because they are typically used to control totalizingmeters. It is the responsibility of the game computer to use the driversappropriately.

2.1.2. Pulse Meter Message

The pulse meter message allows a lamp/relay driver to be pulsed for aprogrammed number of times as defined by a four character ASCIIHexadecimal number string. The pulse meter message uses only lamp/relaydrivers 13 and 14 to control the two totalizing meters found in mostconfigurations. The pulse meter message definition is:

-   -   ‘M’{d}{hh}        The ASCII Decimal digit {h} defines which lamp/relay driver will        be pulsed. The valid range for {d} is 1 (‘1’) to 2 (‘2’). Pulses        for meter 1 are sent to lamp/relay 13. Those for meter 2 are        sent to lamp/relay driver 14. The two digit ASCII Hexadecimal        number {hh} represents the number of pulses sent to the        addressed lamp/relay driver. The valid range for {hh} is 1(‘1’)        to 255(“FF”)

The pulse meter message causes the addressed board to begin pulsing theselected meter's lamp/relay driver with a pulse train equivalent to fivepulses per second. This rate is adequate for most totalizing meters.

The PLAYER and CONCENTRATOR boards accept additional pulse metermessages from the game computer before the previous pulse meter messagehas been completed. The firmware maintains the meter pulse count formeter in internal 16-bit registers. It is the responsibility of the gamecomputer not to cause an overflow of these meter pulse count registers.The firmware sends a status message to the game computer whenever eitherpulse meter count register decrements to zero, thus completing thecommand.

2.1.3. Dispense Ticket Message The dispense ticket message commands thePLAYER or the CONCENTRATOR boards to dispense a programmable number oftickets as defined by a four character ASCII Hexadecimal number string.The pulse meter message definition is:

-   -   ‘T’{hh}        The two digit ASCII Hexadecimal number {hh} represents the        number of tickets to be dispensed from the ticket dispenser. The        valid range for {hh} is 1(‘1’) to 255 (“FF”).

The dispense ticket message causes the addressed board to begindispensing tickets at the rate of the attached ticket dispenser. ThePLAYER and CONCENTRATOR boards accept additional dispense ticketmessages from the game computer before the previous dispense ticketmessage has been completed. The firmware maintains the ticket dispensecount in a 16-bit internal register. It is the responsibility of thegame computer not to overflow the ticket dispense count register. Thefirmware sends a status message to the game computer whenever the ticketdispense count register decrements to zero, thus completing the command.

2.1.4. Dispense Tokens Message

The dispense tokens message commands the PLAYER or the CONCENTRATORboard to dispense a programmable number of tokens as defined by a fourcharacter ASCII Hexadecimal number string. The pulse meter messagedefinition is:

-   -   ‘H’{hh}.

The two digit ASCII Hexadecimal number {hh} represent the number oftokens to be dispensed from the token dispenser's hopper. The validrange for {hh} is 1(‘1’) to 255 (“FF”).

The dispense token message causes the addressed board to begindispensing tokens at the rate of the attached token dispenser. ThePLAYER and CONCENTRATOR boards accept additional dispense tokensmessages from the game computer before the previous dispense tokensmessage has been completed. The firmware maintains the token dispensecount in a 16-bit internal register. It is the responsibility of thegame computer not to overflow the token dispense count register.Firmware sends a status message to the game computer whenever the tokendispense count register decrements to zero, thus completing the command.

2.1.5. Display Data Message

A numeric display capable of displaying two eight digit numbers,including a decimal point, can be controlled by either the PLAYER orCONCENTRATOR board. The boards automatically determine during boardinitialization whether an LED display module is connected to the LEDdisplay serial port. If an LED display is found, the boards direct thedata to the LED display module, otherwise the boards assume that an LCDdisplay module is attached and direct the data to that display. Thedisplay data message definition is: ‘D’{d}{NULL-terminated ASCII Decimalnumeric string). The ASCII decimal digit {d} selects into which of thetwo supported display fields the ASCII decimal numeric string will bedisplayed. The valid values for {d} is 1(‘1’) or 2(‘2’). Validcharacters for the ASCII decimal numeric string elements are ‘0’ to ‘9’and ‘.’.

The numeric string is displayed as transmitted. It is responsibility ofthe game computer to transmit a valid numeric string. A maximum of eightcharacters, excluding the decimal point, may be displayed in each field.If more than eight digits are transmitted, the display is only updatedwith the first eight characters received.

2.2. CONCENTRATOR-Only Output Messages

There is one output message specific to the CONCENTRATOR board.

2.2.1. Set Baud Rate Message

This message allows the game computer to control the baud rate of allthe serial ports installed on the CONCENTRATOR. Each PLAYER board isconnected to the CONCENTRATOR using a serial port. These ports havedefined baud rates of 9600 baud. Since this message is specific to theCONCENTRATOR, the game computer should not change the baud rate of theserial ports connected to the PLAYER boards.

The printer and the progressive sign are serial devices connected to theCONCENTRATOR. For these devices, the baud rate may vary. Thus, themessage is intended to allow the game computer to program the baud rateof the serial ports to which these two devices are connected. Table 3defines the default configuration and connectivity of the availableserial ports.

The format for the set band rate message is:

-   -   ‘Z’{h}{speed code}{‘8’|‘7’}{‘N’|‘E’|‘0’}{‘1’|‘2’}.        The ASCII Hexadecimal digit {h} defines the serial port to be        programmed. Table 4 defines the character {speed code} used to        define the baud rate for the port to be programmed.

TABLE 3 SERIAL PORT MAP Device Port # Address Configuration PLAYER 1 0‘A’ 9600, 8, N, 1 PLAYER 2 1 ‘B’ 9600, 8, N, 1 PLAYER 3 2 ‘C’ 9600, 8,N, 1 PLAYER 4 3 ‘D’ 9600, 8, N, 1 PLAYER 5 4 ‘E’ 9600, 8, N, 1Progressive 5 ‘S’ 2400, 8, N, 1 Printer 6 ‘P’ 9600, 8, N, 1 Spare 1 7 —9600, 8, N, 1 Spare 2 8 — 9600, 8, N, 1 Spare 3 9 — 9600, 8, N, 1 Spare4 10 — 9600, 8, N, 1 Spare 5 11 — 9600, 8, N, 1 Spare 6 12 — 9600, 8, N,1 Spare 7 13 — 9600, 8, N, 1 Spare 8 14 — 9600, 8, N, 1 Spare 9 15 —9600, 8, N, 1

TABLE 4 SERIAL PORT SPEED CODES Baud Rate Speed Code 300 ‘A’ 600 ‘B’1200 ‘C’ 2400 ‘D’ 4800 ‘E’ 9600 ‘F’ 19200 ‘G’ 38400 ‘H’

2.3. Progressive Sign and Printer Output Messages

Messages to the progressive sign or to the printer are formattedaccording to the general output message format specified in section 1.1.The CONCENTRATOR board simply routes the data field of the generalmessage format to the serial port connected to the addressed device: theprogressive sign or the printer. The format of the data field is whollycontrolled by the game computer. The CONCENTRATOR does not parse thedata field except to find the terminating ASCII NULL. Thus, the datafield of the output messages directed to these two devices cannotinclude ASCII NULLs.

2.4. General Purpose Control Messages

The PLAYER and CONCENTRATOR boards may be controlled completely with thetwo messages defined in this section. The output messages defined insections 2.1 and 2.2 are designed to allow the PLAYER/CONCENTRATOR tooff-load some of the burden of explicitly controlling or polling eachperipheral device function. The two messages defined in this sectionallow the game computer more explicit control of the various devicefunctions of the PLAYER and CONCENTRATOR boards and to determine thestatus of the PLAYER and CONCENTRATOR boards.

2.4.1. Read Register Message

The read register message allows the game computer to explicitly readthe contents of the internal register being used by thePLAYER/CONCENTRATOR board firmware for various input, control, or statusfunctions. The syntax for this message is:

-   -   ‘R’{h}.

The ASCII Hexadecimal digit {h} is the address of the internal registerto be read. Table 5 defines the register addresses that may be read.Each register defined in Table 5 is an 8-bit register the contents ofwhich are returned to the game computer as a status message.

TABLE 5 READ REGISTER ADDRESSES Name Function Address Digital Input #1Push-button Bank 1 ‘1’ Digital Input #2 Push-button Bank 2 ‘2’ DigitalInput #3 General Purpose Inputs ‘3’ Digital Input #4 DIP Switches ‘4’Digital Input #5 Meter #1 Count (low) ‘5’ Digital Input #6 Meter #1Count (high) ‘6’ Digital Input #7 Meter #2 Count (low) ‘7’ Digital Input#8 Meter #2 Count (high) ‘8’ Digital Input #9 Token Count (low) ‘9’Digital Input #10 Token Count (high) ‘A’ Digital Input #11 Ticket Count(low) ‘B’ Digital Input #12 Ticket Count (high) ‘C’ Status RegisterFPGA/Firmware Status ‘F’

2.4.2. Write Register Message

The read register message allows the game computer to explicitly readthe contents of the internal register being used by thePLAYER/CONCENTRATOR board firmware for various input, control, or statusfunctions. The syntax from this message is:

-   -   ‘W’{h}{hh}.        The ASCII Hexadecimal digit {h} is the address of the internal        register to be read. The two ASCII Hexadecimal digit {hh}        defines the data to be written to the selected internal        register. Table 6 defines the register addresses that may be        read. Each register defined in Table 6 is an 8-bit register the        contents of which will be modified to the value contained in the        write register message.

TABLE 6 WRITE REGISTER ADDRESSES Name Function Address Digital Output #1Lamp Bank 1 ‘1’ Digital Output #2 Lamp Bank 2 ‘2’ Digital Output #3General Purpose Outputs ‘3’ Digital Output #4 General Purpose Outputs‘4’ Digital Output #5 Meter #1 Count (low) ‘5’ Digital Output #6 Meter#1 Count (high) ‘6’ Digital Output #7 Meter #2 Count (low) ‘7’ DigitalOutput #8 Meter #2 Count (high) ‘8’ Digital Output #9 Token Count (low)‘9’ Digital Output #10 Token Count (high) ‘A’ Digital Output #11 TicketCount (low) ‘B’ Digital Output #12 Ticket Count (high) ‘C’ ControlRegister FPGA/Firmware Control ‘F’

3. Input Messages: PLAYER/CONCENTRATOR

Section 2 defined the output messages from the game computer to eitherthe PLAYER or the CONCENTRATOR board. This section defines the messagesfrom the PLAYER and CONCENTRATOR boards to the game computer. The inputmessages to the game computer are presently classified into four types:error, status, credit action, and push-button action. These messages aresent by the PLAYER board through the serial port to the CONCENTRATORboard's keyboard port to the game computer. While the CONCENTRATOR boardalso sends these messages to the game computer, it does so only throughthe keyboard connector. The CONCENTRATOR board translates all inputmessages into keyboard keycode sequences.

This section defines the input messages from the PLAYER/CONCENTRATOR asASCII sequences. There are input messages common to both the PLAYER andCONCENTRATOR boards as well as messages that originate only from theCONCENTRATOR board. The common input messages are defined in subsection3.1. The CONCENTRATOR-specific input messages are defined in subsection3.2. The translation of the ASCII input messages into keyboard keycodesequences are defined in section 4.

3.1. Common Input Messages

This subsection defines the common input messages for the PLAYER and theCONCENTRATOR boards. The four input message types follow the same basicformat as defined in subsection 1.2. Refer to Table 1 and to Table 2 forthe address and type identifiers.

3.1.1. Common Error Input Messages

The error input message definition is:

-   -   ‘?’{a}{hh}.        The ASCII character {a} defines the address of the source as        defined in Table 1. The two character ASCII Hexadecimal number        {hh} identifies the error code. The currently defined error        codes are provided in Table 7.

TABLE 7 COMMON ERROR CODES Detected Error Code FPGA Reloaded/Power-OffIntrusion “80” Token Hopper Overflow “40” Token Hopper Empty “20” TicketDispenser Empty “10”

3.1.2. Common Status Input Messages

There are two kind of status input messages: solicited and unsolicited.Solicited status input messages are sent to the game computer as aresult of a direct request. Direct requests for status input messagesare made using the read register output message.

Unsolicited status input messages are sent to the game computer as aresult of the error free completion of an action initiated by an outputmessage. For example, unsolicited status input messages are returned bythe pulse meter, the dispense ticket, and the dispense token outputmessages whenever the appropriate count register decrements to zero.

The status input message format is:

-   -   ‘!’{a}{h}{hh}.        The ASCII character {a} is the address of the source as defined        by Table 1. The single ASCII Hexadecimal digit {h} is the read        register codes for the two ASCII Hexadecimal digit {hh} data        which follows. The read register codes are given in Table 5. The        read register “F” is used to identify unsolicited status input        messages. Table 8 defines the four unsolicited status input        message data fields currently defined.

TABLE 8 UNSOLICITED STATUS RESPONSE CODES Status Indication Status CodeToken Dispensing Complete “08” Ticket Dispensing Complete “04” Meter #2Count Complete “02” Meter #1 Count Complete “01”

3.1.3. Common Credit Action Input Message

The PLAYER and CONCENTRATOR boards are designed to accept both a serialoutput dollar bill acceptor (DBA), or a pulsed output DBA. The creditaction message is defined to efficiently notify the game computer of thecredit code received from a serial output DBA. Neither the PLAYER boardor the CONCENTRATOR board interpret the credit code received. It is theresponsibility of the game computer to process the credit action inputmessage and to send a pulse meter output message to the appropriateboard in order to record the appropriate number of credits on atotalizing meter.

The credit action input message format is:

-   -   ‘$’{a}{hh}.        The ASCII character {a} is the address of the source as defined        in Table 1. The two digit ASCII Hexadecimal number {hh} is the        code sent by the DBA.

No interpretation of that code is performed by the PLAYER firmware orthe CONCENTRATOR firmware with respect to the value of the currencyaccepted by the DBA. The PLAYER/CONCENTRATOR does process thecontrol/status codes received from the DBA in order the maintain controlof the DBA. The range of values that the game computer should expect forthe DBA credit action input message data filed is 129(“81”) to133(“85”). Table 9 defines the complete set of values that the PLAYER orCONCENTRATOR expects to receive from the DBA. The values providedrepresent the definition for CashCode-compatible serial output DBAs. TheDBA message codes defined in Table 9 also include several error codes,beginning with “failure detected.” These error codes are reported usingthe credit action input message rather than the error input message.

TABLE 9 CREDIT ACTION INPUT MESSAGE CODES DBA Message Hex Code $1 Credit“81” $2 Credit “82” $5 Credit “83” $10 Credit “84” $20 Credit “85”reserved “86” reserved “87” Vend “89” Bill Returned “8A” Bill Rejected“8B” Failure Detected “8C” Stacker Full “8D” Lockable Cassette Removed“8E” Lockable Cassette Attached “8F”

3.1.4. Common Push-Button Action Input Messages

The PLAYER and CONCENTRATOR boards implement digital input switchdebouncing on the first 16 digital inputs. These inputs are thus treatedas push-buttons. The firmware debounces the closing or opening ofexternal switches. Only fully debounced changes of state are sent aspush-button input messages to the game computer. The firmware alsoprevents the simultaneous closure of two or more switches. This does notmean that the game computer cannot implement multi-button logic, but itdoes require that the game computer use the more general purpose readregister output message to read the sate of multiple switchessimultaneously. The firmware reports the closing of a push-button usinga lower case alphabetic ASCII character, and it reports the opening ofthe switch as an upper case alphabetic character. Each push-button, PB1through PB16, is reported as ‘A’ through ‘P’ or ‘a’ through ‘p’,depending on whether the push-button is being opened or closed,respectively. The format for this input message type is:

-   -   ‘@’{a}{‘A’ . . . ‘P’|‘a’ . . . ‘p’}.        The ASCII character {a} defines the source of the push-button        action input menages as defined by Table 1.

3.2. CONCENTRATOR-Specific Input Messages

The preceding subsection defined the common input messages for thePLAYER and CONCENTRATOR boards. At this time there are noCONCENTRATOR-specific input messages defined.

4. ASCII Messages Keycode Translation

A primary difference between the message translation of the CONCENTRATORboard firmware and that of the PLAYER firmware is that the CONCENTRATORboard firmware translates all messages to be sent to the game computerinto IBM PC/AT-compatible keyboard keycode sequences. It also sends allinput messages to the game computer via the game computer's keyboardport. This section defines a keycode translation table for all the ASCIIinput messages.

4.1. Push-Button Keyboard Scan Code Translation Matrix

Table 10 defines the translation of the push-button action inputmessages into keycodes compatible with the game system. In the table,N0-N9 represent the ten keycodes for the keyboard's number pad; F1-F6represent the function keys; and keycodes preceded with a lower case Sindicate that the keycode is preceded with the keycode with the leftshift button.

TABLE 10 PUSH-BUTTON KEYCODE TRANSLATION TABLE PB# ASCII Code PS#1 PS#2PS#3 PS#4 PS#5 CONC 1 ‘A’, ‘a’ N0 0 A I Q Pause 2 ‘B’, ‘b’ N7 7 H P X N93 ‘C’, ‘c’ N5 5 F N V Enter 4 ‘D’, ‘d’ N1 1 B J R ESC 5 ‘E’, ‘e’ N2 2 CK S TAB 6 ‘F’, ‘f’ N6 6 G O W / 7 ‘G’, ‘g’ N8 8 Space Y Z Scroll Lock 8‘H’, ‘h’ N3 3 D L T Num Lock 9 ‘I’, ‘i’ N4 4 E M U Caps Lock 10 ‘J’, ‘j’F1 F2 F3 F4 F5 F6 11 ‘K’, ‘k’ sA sG sM sS sY BS 12 ‘L’, ‘l’ sB sH sN sTsZ Del 13 ‘M’, ‘m’ sC sI sO sU s0 Ins 14 ‘N’, ‘n’ sD sJ sP sV s3 Home 15‘O’, ‘o’ sE sK sQ sW s6 End 16 ‘P’, ‘p’ sF sL sR sX s9 NEnterThe keycode scan code require the CONCENTRATOR firmware to generate bothmake and break sequences during the translation process. Thus, Tables 11through 16 provide scan code sequences for each of five player stationsand the CONCENTRATOR to document the keyboard scancode sequence requiredin the translation tables for the push-button action input messages.

TABLE 11 PLAYER STATION #1 SCAN CODE SEQUENCES Make Break PB# Code MakeSequence Code Break Sequence 1 ‘a’ 0x70 ‘A’ 0xF0, 0x70 2 ‘b’ 0x6C ‘B’0xF0, 0x6C 3 ‘c’ 0x73 ‘C’ 0xF0, 0x73 4 ‘d’ 0x69 ‘D’ 0xF0, 0x69 5 ‘e’0x72 ‘E’ 0xF0, 0x72 6 ‘f’ 0x74 ‘F’ 0xF0, 0x74 7 ‘g’ 0x75 ‘G’ 0xF0, 0x758 ‘h’ 0x7A ‘H’ 0xF0, 0x7A 9 ‘i’ 0x6B ‘I’ 0xF0, 0x6B 10 ‘j’ 0x05 ‘J’0xF0, 0x05 11 ‘k’ 0x12, 0x16 ‘K’ 0xF0, 0x16, 0xF0, 0x12 12 ‘l’ 0x12,0x32 ‘L’ 0xF0, 0x32, 0xF0, 0x12 13 ‘m’ 0x12, 0x21 ‘M’ 0xF0, 0x21, 0xF0,0x12 14 ‘n’ 0x12, 0x23 ‘N’ 0xF0, 0x23, 0xF0, 0x12 15 ‘o’ 0x12, 0x24 ‘O’0xF0, 0x24, 0xF0, 0x12 16 ‘p’ 0x12, 0x2B ‘P’ 0xF0, 0x2B, 0xF0, 0x12

TABLE 12 PLAYER STATION #2 SCAN CODE SEQUENCES Make Break PB# Code MakeSequence Code Break Sequence 1 ‘a’ 0x45 ‘A’ 0xF0, 0x45 2 ‘b’ 0x3D ‘B’0xF0, 0x3D 3 ‘c’ 0x2E ‘C’ 0xF0, 0x2E 4 ‘d’ 0x16 ‘D’ 0xF0, 0x16 5 ‘e’0x1E ‘E’ 0xF0, 0x1E 6 ‘f’ 0x36 ‘F’ 0xF0, 0x36 7 ‘g’ 0x3E ‘G’ 0xF0, 0x3E8 ‘h’ 0x26 ‘H’ 0xF0, 0x26 9 ‘i’ 0x25 ‘I’ 0xF0, 0x25 10 ‘j’ 0x06 ‘J’0xF0, 0x06 11 ‘k’ 0x12, 0x34 ‘K’ 0xF0, 0x34, 0xF0, 0x12 12 ‘l’ 0x12,0x33 ‘L’ 0xF0, 0x33, 0xF0, 0x12 13 ‘m’ 0x12, 0x43 ‘M’ 0xF0, 0x43, 0xF0,0x12 14 ‘n’ 0x12, 0x3B ‘N’ 0xF0, 0x3B, 0xF0, 0x12 15 ‘o’ 0x12, 0x42 ‘O’0xF0, 0x42, 0xF0, 0x12 16 ‘p’ 0x12, 0x4B ‘P’ 0xF0, 0x4B, 0xF0, 0x12

TABLE 13 PLAYER STATION #3 SCAN CODE SEQUENCES Make Break PB# Code MakeSequence Code Break Sequence 1 ‘a’ 0x16 ‘A’ 0xF0, 0x16 2 ‘b’ 0x33 ‘B’0xF0, 0x33 3 ‘c’ 0x2B ‘C’ 0xF0, 0x2B 4 ‘d’ 0x32 ‘D’ 0xF0, 0x32 5 ‘e’0x21 ‘E’ 0xF0, 0x21 6 ‘f’ 0x34 ‘F’ 0xF0, 0x34 7 ‘g’ 0x29 ‘G’ 0xF0, 0x298 ‘h’ 0x23 ‘H’ 0xF0, 0x23 9 ‘i’ 0x24 ‘I’ 0xF0, 0x24 10 ‘j’ 0x04 ‘J’0xF0, 0x04 11 ‘k’ 0x12, 0x3A ‘K’ 0xF0, 0x3A, 0xF0, 0x12 12 ‘l’ 0x12,0x31 ‘L’ 0xF0, 0x31, 0xF0, 0x12 13 ‘m’ 0x12, 0x44 ‘M’ 0xF0, 0x44, 0xF0,0x12 14 ‘n’ 0x12, 0x4D ‘N’ 0xF0, 0x4D, 0xF0, 0x12 15 ‘o’ 0x12, 0x15 ‘O’0xF0, 0x15, 0xF0, 0x12 16 ‘p’ 0x12, 0x2D ‘P’ 0xF0, 0x2D, 0xF0, 0x12

TABLE 14 PLAYER STATION #4 SCAN CODE SEQUENCES Make Break PB# Code MakeSequence Code Break Sequence 1 ‘a’ 0x15 ‘A’ 0xF0, 0x15 2 ‘b’ 0x22 ‘B’0xF0, 0x22 3 ‘c’ 0x2A ‘C’ 0xF0, 0x2A 4 ‘d’ 0x2D ‘D’ 0xF0, 0x2D 5 ‘e’0x1B ‘E’ 0xF0, 0x1B 6 ‘f’ 0x1D ‘F’ 0xF0, 0x1D 7 ‘g’ 0x1A ‘G’ 0xF0, 0x1A8 ‘h’ 0x26 ‘H’ 0xF0, 0x26 9 ‘i’ 0x3C ‘I’ 0xF0, 0x3C 10 ‘j’ 0x03 ‘J’0xF0, 0x03 11 ‘k’ 0x12, 0x35 ‘K’ 0xF0, 0x35, 0xF0, 0x12 12 ‘l’ 0x12,0x1A ‘L’ 0xF0, 0x1A, 0xF0, 0x12 13 ‘m’ 0x12, 0x45 ‘M’ 0xF0, 0x45, 0xF0,0x12 14 ‘n’ 0x12, 0x26 ‘N’ 0xF0, 0x26, 0xF0, 0x12 15 ‘o’ 0x12, 0x36 ‘O’0xF0, 0x36, 0xF0, 0x12 16 ‘p’ 0x12, 0x46 ‘P’ 0xF0, 0x46, 0xF0, 0x12

TABLE 15 PLAYER STATION #5 SCAN CODE SEQUENCES Make Break PB# Code MakeSequence Code Break Sequence 1 ‘a’ 0x43 ‘A’ 0xF0, 0x43 2 ‘b’ 0x4D ‘B’0xF0, 0x4D 3 ‘c’ 0x31 ‘C’ 0xF0, 0x31 4 ‘d’ 0x3B ‘D’ 0xF0, 0x3B 5 ‘e’0x42 ‘E’ 0xF0, 0x42 6 ‘f’ 0x44 ‘F’ 0xF0, 0x44 7 ‘g’ 0x35 ‘G’ 0xF0, 0x358 ‘h’ 0x4B ‘H’ 0xF0, 0x4B 9 ‘i’ 0x3A ‘I’ 0xF0, 0x3A 10 ‘j’ 0x0C ‘J’0xF0, 0x0C 11 ‘k’ 0x12, 0x1B ‘K’ 0xF0, 0x1B, 0xF0, 0x12 12 ‘l’ 0x12,0x26 ‘L’ 0xF0, 0x26, 0xF0, 0x12 13 ‘m’ 0x12, 0x3C ‘M’ 0xF0, 0x3C, 0xF0,0x12 14 ‘n’ 0x12, 0x2A ‘N’ 0xF0, 0x2A, 0xF0, 0x12 15 ‘o’ 0x12, 0x1D ‘O’0xF0, 0x1D, 0xF0, 0x12 16 ‘p’ 0x12, 0x22 ‘P’ 0xF0, 0x22, 0xF0, 0x12

TABLE 16 CONCENTRATOR SCAN CODE SEQUENCES PB# Make Code Make SequenceBreak Code Break Sequence 1 ‘a’ 0xE1, 0x14, ‘A’ none 0x77, 0xE1, 0xF0,0x14, 0xF0, 0x77 2 ‘b’ 0x7D ‘B’ 0xF0, 0x7D 3 ‘c’ 0x5A ‘C’ 0xF0, 0x5A 4‘d’ 0x76 ‘D’ 0xF0, 0x76 5 ‘e’ 0x0D ‘E’ 0xF0, 0x0D 6 ‘f’ 0x4A ‘F’ 0xF0,0x4A 7 ‘g’ 0x7E ‘G’ 0xF0, 0x7E 8 ‘h’ 0x77 ‘H’ 0xF0, 0x77 9 ‘i’ 0x58 ‘I’0xF0, 0x58 10 ‘j’ 0x0B ‘J’ 0xF0, 0x0B 11 ‘k’ 0x56 ‘K’ 0xF0, 0x56 12 ‘l’0xE0, 0x71 ‘L’ 0xE0, 0xF0, 0x71 13 ‘m’ 0xE0, 0x70 ‘M’ 0xE0, 0xF0, 0x7014 ‘n’ 0xE0, 0x6C ‘N’ 0xE0, 0xF0, 0x6C 15 ‘o’ 0xE0, 0x69 ‘O’ 0xE0, 0xF0,0x69 16 ‘p’ 0xE0, 0x5A ‘P’ 0xE0, 0xF0, 0x5A

4.2. Error, Status, and Credit Action Scan Code Translation

These input message types follow a prescribed message format definedabove in section 3. This section defines the scan code sequences forthese messages by first defining the scan code alphabet the messagetypes must use. An alphabet of scan codes can be defined because thesemessage types use only a finite number of ASCII codes to form each inputmessage. The ASCII character alphabet for these messages is:

-   -   {‘?’,‘!’,‘$’,‘@’,‘0’ . . . ‘9’,‘A’ . . . ‘F’,‘P’,‘S’}.

Table 17 defines the make and break scan code sequences for thesemessage types.

TABLE 17 SCAN CODES FOR ERROR, STATUS, AND CREDIT ACTION MESSAGES ASCIIMake Break ASCII Make Break ‘?’ 0x03 0xF0, 0x03 ‘0’ 0x45 0xF0, 0x45 ‘!’0x0C 0xF0, 0x0C ‘1’ 0x16 0xF0, 0x16 ‘$’ 0x04 0xF0, 0x04, 0xF0, 0x12 ‘2’0x1E 0xF0, 0x1E ‘A’ 0x16 0xF0, 0x16 ‘3’ 0x26 0xf0, 0x26 ‘B’ 0x32 0xF0,0x32 ‘4’ 0x25 0xF0, 0x25 ‘C’ 0x21 0xF0, 0x21 ‘5’ 0x2E 0xF0, 0x2E ‘D’0x23 0xF0, 0x23 ‘6’ 0x36 0xF0, 0x36 ‘E’ 0x24 0xF0, 0x24 ‘7’ 0x3D 0xF0,0x3D ‘F’ 0x2B 0xF0, 0x2B ‘8’ 0x3E 0xF0, 0x3E ‘P’ 0x4D 0xF0, 0x4D ‘9’0x46 0xF0, 0x46 ‘S’ 0x1B 0xF0, 0x1B ‘@’ 0x06 0xF0, 0x06

As an example, the Token Hopper overflow Error input message from playerstation 1 may be written as

-   -   “?A80”.        That message would consist of the following scan code sequence        0x03, 0×F0, 0x03, 0x16, 0xF0, 0x16, 0x3E, 0xF0, 0x3E, 0x45,        0×F0, 0x45.

As the above scan code sequence indicates, each “key stroke” consists ofthe make scan code immediately followed by the break scan code for thesame key. An exception is that the break scan code for the left shiftkey follows the break scan code for the key being shifted.

1. A multi-player platform that provides multiple player stations forlive players to engage in a video card game with virtual cardscomprising: at least two player stations that enable live players toplace wagers on said video card game; a single video display viewablefrom each of said player stations; means programmed with steps forplaying said card game for displaying simultaneously upon said singlevideo display all cards that have been initially dealt to each player,and a game processor that contains the rules of the video card game, theprocessor enabling play for each player on the video card game accordingto a set of rules; means for metering a plurality of predefined eventsand game play statistics for each player station; and a remote computerin operative communication with said game processor; wherein said gameprocessor is first programmed to operate said video gaming program;determine an outcome of said gaming program for each player station;display said outcome on said display monitor and communicate saidoutcome to said player station output devices; second, to receive playerstation event information from said event monitoring means in each saidplayer station; and record said event information in said metering meansuniquely to each player station; and third, to calculate game statisticsrespective to each player station from said game play outcome; andrecord said game play statistics in said metering means uniquely to eachplayer station.
 2. The platform of claim 1 wherein the video card gameis blackjack.
 3. The platform of claim 1 wherein the video card game ispoker.
 4. The platform of claim 1 wherein said player input devices arebuttons.
 5. The platform of claim 1 wherein said player output devicesinclude lamps.
 6. The platform of claim 1 wherein said remote computeris programmed, to operate a progressive jackpot feature in which allcommunication player stations may participate.
 7. A multi-player systemthat provides multiple player stations for live players to engage in avideo card game, said system comprising: a) two or more multi-playervideo card gaming platforms, each said platform including: a pluralityof two or more spatially separate player stations, each said playerstation including: at least one input device for allowing a player toenter game play selections into said system; at least one output devicefor communicating game play outcome to a player; and means formonitoring a plurality of events at said player station; a gameprocessor interfaced to said plurality of player stations; and a singledisplay monitor connected to said game processor for displaying gameplay of each player station together; wherein, said game processor isprogrammed first to execute a multiplayer video card gaming program inresponse to inputs received from said player station input devices,determine an outcome of said gaming program for each player station,display said outcome on said display monitor and communicate saidoutcome to said player station output devices; and second, to receiveplayer station event information from said event monitoring means ineach said player station and, in response thereto, record said eventinformation in said metering means uniquely to each player station; andb) a remote computer interfaced to each of said two or more multi-playervideo card gaming platforms, wherein, said remote computer is inoperative communication with each respective game processor of saidmulti-player video card gaming platforms and said remote computer isprogrammed to run a progressive jackpot feature in which allcommunicating player stations upon each said multi-player video cardgaming platform may participate.
 8. The system of claim 7 wherein uponone or more said multi-player video card gaming platforms said videocard gaming program is blackjack.
 9. The system of claim 7 wherein uponone or more said multi-player video card gaming platforms said videocard gaming program is poker.
 10. The system of claim 7 wherein upon oneor more said multi-player video card gaming platform the video cardgaming program is blackjack and upon one or more said multi-player videocard gaming platform the video card gaming program is poker.
 11. Thesystem of claim 7 wherein upon one or more said multi-player video cardgaming platforms said player input devices include buttons.
 12. Thesystem of claim 7 wherein upon one or more said multi-player video cardgaming platforms each said player station includes a ticket dispensingmeans.